Pixabay/ CC0

 Overview

Ethics is an area of study involving what is acceptable and what is not acceptable in association with personal and professional obligation.  Ethical behaviour requires that actions are taken which assume that someone will find out, regardless of whether or not they actually do. 

Ethics

In examining the triangle above, the arrows are meant to indicate possible conflicts that must be balanced.  To remain on the correct ethical path, the desires shown in each box would need to be met.  However, an engineer who wishes to advance his or her career may see opportunities that might increase their visibility and chance of advancement, but those opportunities are not always consistent with the company’s advancement.  What if an engineer sees an opportunity to take a technological advancement they created at one company and move to a different firm, taking the technological advancement with them to bolster their career with the new job?  Is that ethical?  If a an engineer discovers that their company has taken a short-cut on a safety consideration that could have a safety impact on the customer, then the desires of the two lower boxes in the triangle can come into conflict.  The most ethical path must consider all three desires and keep them in balance.

Ethical errors end careers more quickly than any other mistake in judgment.  Nothing is more dangerous to a business than a tarnished public image.  Many companies have suffered severe business losses and even had to close down, due to the negative public reaction to an ethical breach.  Ethics provides the broader framework within which business life must be understood.

Professional ethics are a set of principles of professional conduct which have been evolved by practice for the greatest good of that profession and of the public at large.  Professional Ethics differs from Law in that it limits itself to the members of the profession concerned.  It arises from an intelligent analysis of the subject under question by members of the profession.  It is less mandatory than law and relies largely upon morals.

Professional ethics are a set of principles of professional conduct which have been evolved by practice for the greatest good of that profession and of the public at large.  Professional Ethics differs from Law in that it limits itself to the members of the profession concerned.  It arises from an intelligent analysis of the subject under question by members of the profession.  It is less mandatory than law and relies largely upon morals.

There is a natural tendency to justify one’s ethical behaviour against the behaviour of others.  How many of us have heard someone say something along the lines of “Well, what I did was nothing compare to what that other person did wrong”  Is that a valid response?  Can an action be acceptable just because it is “less wrong” than someone else?  Consider this quote by a well-known scientist:

“Relativity applies to physics, not ethics” …..Albert Einstein (Hulme, 2003)

How we behave influences those around us.  We have probably all seen a young child emulating the actions and behaviours of their parent.  If the parent exhibits unethical behaviour, is it not logical that we would expect to see the child follow suit?  In the business world, if we are leaders in our organization, the way we behave sets the tone for how the other members of our organization will behave.  Consider this quote by a famous theologian, writer, humanitarian, philosopher, and physician:

“Example is not the main thing in influencing others…….it is the ONLY thing.”  ...Albert Schweitzer (BrainyQuote, 2017)

Application scenarios

Summary

Ethics is an area of study involving what is acceptable and what is not acceptable in association with personal and professional obligation.  Ethical behaviour requires that actions are taken which assume that someone will find out, regardless of whether or not they actually do.

Ethics is an area of study involving what is acceptable and what is not acceptable in association with personal and professional obligation.  Ethical behaviour requires that actions are taken which assume that someone will find out, regardless of whether or not they actually do.

A design engineer’s task usually begins when a problem or a need is identified.  This may occur because something has failed, or is recognized as not working as efficiently as would be desired.   It may also occur because someone has recognized a void in the marketplace that presents an opportunity for a new product to be produced and sold.  Or it may occur because of a technology breakthrough that opens the door to a previously unexploited market.  Regardless of how things arise, the objective of the design engineer is to solve the identified problem or meet the identified need.

The engineer is faced with how to exploit this opportunity by coming up with a solution to the problem which is both feasible and cost-effective and determining a way to produce that solution.   In order to do this, the design engineer or the engineering design team must assess the problem/opportunity and determine the requirements for a solution.

It may be that a customer has come to the design team with a concept already in mind, and that customer may even have already dictated the requirements and specifications that must be met by any possible solution.  In this case, the design team must first understand the goals and objectives of the bespoke project and synthesize the top-level requirements and specifications so that the needs of the customer are thoroughly understood.  The design team may then add second-level requirements and specifications that the customer did not originally address.  These would be further limitations that the design team chooses to place upon their solution based on their experience, capabilities, resources, etc. 

It may otherwise be the case that a problem or need has been brought to the design team, with no preconceived solution in mind.  In this case, the design team must evaluate the problem that needs to be solved, and to create their own requirements and specifications that would enclose the envelope that encompasses the possible designs that could meet the need and solve the problem.  This is frequently referred to as the Design Space of the problem.  These become the top-level requirements for the project.  The second-level requirements are then developed, again based upon the limitations previously mentioned such as experience, capability and resources.   Following this, the design team must Brainstorm possible solutions, thinking of as many possible approaches to solving the problem as possible.  Brainstorming involves open-ended thinking that produces a wide range of possible solution approaches that meet the requirements which have been developed.  At this initial stage, the team should not consider any suggested solution as a “bad” idea, but rather, should simply let the creative thought process produce as many potential solutions as possible. 

Once this list of solutions is produced, the team begins the process of evaluation and down-select, eliminating the least feasible solutions until only the best one remains.  The design process then continues as delineated in the Design Process steps of the following topic.

The Design Process

While different organizations may use different design process steps, the ones listed below encompass the most commonly used activities.

1. Assess team skills and get to know each other – This is particularly important if the design team has never met previously, or never worked together as a team. It is not necessary if the team is established and has worked as a team before.  It is important, as the process goes on, that team members know who can be relied upon for what tasks.  Therefore, this is a key first stage for any new team.
2. Develop preliminary schedule – Based upon the time constraints of the project, such as when the required solution is to be implemented or when the customer expects delivery, the team should create a preliminary project schedule. Doing this at the beginning allows the team to assess how much time can be allocated to each step of the design process.  How this schedule is created and tracked throughout the design process will be discussed in a subsequent section.
3. Study first level design requirements – These may be provided by the customer, or they may have to be developed by the design team as they evaluate the problem or need which is to be met by the solution they are tasked with delivering.
4. Derive second level requirements - These are controlled by the design team, and are developed based upon experience, capabilities, resources, etc.
5. Brainstorm concepts – Design team members allow their creativity to free-roam, producing as many possible solution approaches as possible. No attempt to evaluate them is made at this time, only to make as complete a list of possible solutions as the team can collectively think of.
6. Make team assignments – It is now time to begin evaluating the concepts that arose during brainstorming. Individual design team members should be tasked with further evaluation of various concepts relative to how well they can meet the first and second level requires and how practical they are.  It is good to know individual team member strengths and capabilities (as determined in step 1) to efficiently distribute the work load across the various team members.
7. Evaluate/eliminate concepts – Individual design team members perform their assigned evaluations, and return as a group to discuss. Solutions which are not feasible or which do not meet requirements, are readily eliminated, based upon the consensus of the entire team.  This becomes an iterative process, as some solutions are eliminated, and further evaluation may be required for those that remain on the list.
8. Down-select to one concept – Ultimately, the goal of the design team is to reduce the long list of brainstormed solutions down to the single most practical solution, and that is the one that will be designed. This should include a preliminary examination of the selected solution to ensure that it can fit within the available resources and meet the project specifications and requirements.
9. Concept Readiness Review – This review goes by different names in different industries. However its purpose is always to examine the general concept that has been selected by the design team during the previous stages, and to present that concept, and the rationale that supports it, to a team of reviewers which may include representatives of the customer, of your company’s management, and experts in the field.  Topics to be covered in the review should include:

• Design objective
• Design requirements
• Selected concept
• Discussion of why the selected concept is a good choice
• Discussion of any noteworthy aspects of unselected concepts and why they were not selected
• Risk assessment
• Preliminary cost assessment
• Schedule and go-forward plan

10. Evaluate Risks – It is never too early to begin evaluating the risks to success of the project. The earlier that a potential risk is identified and is resolved, the easier it is to find a way to eliminate, or mitigate the risk. The simplest approach is to simply brainstorm all the potential failures that could befall the project, and then evaluate each of them to determine how likely they are to occur and how damaging they would be if they did.  A thorough and methodical approach to technical risk evaluation and management is the best approach, and a sample approach will be presented in a subsequent section.
11. Work on the preliminary design – Having received approval to proceed, following the concept review, the design team should now begin consideration of the following questions, once again assigning appropriate individuals to their consideration:

• Patent search – Will the design run afoul of patent laws and existing patents?
• Market research – How will the proposed solution fit in the marketplace? Will it be marketable at the cost that is expected to be required for production?  Is there a viable marketing strategy to get customers to buy the product?
• Cost and schedule analysis – How much will the product cost to produce? Where is the team relative to the preliminary schedule developed earlier, and do adjustments need to be made?
• Concept development – What are the steps required in order for the project to advance from the concept to a preliminary design which must be completed to take the project to the next level?

12. Analyze preliminary design – Technical evaluation of the preliminary design will be required to assess preliminary configuration, parts sizing, materials, et cetera. This may take the form of hand calculations or may involve preliminary computer modeling.
13. Preliminary design drawings/sketches – The actual configuration of the bits that will comprise the solution need to be developed as sketches and then preliminary drawings or models.
14. Refine/Modify design as necessary – As the design effort progresses, it will be recognized that there are changes required in order to make the design work, or to optimize the result.
15. Update risks, budget and schedule - The changes mentioned in step 14 must be incorporated into the design and their impacts on cost, scheduled and risk must be considered.
16. Preliminary Design Review - This review goes by different names in different industries. However its purpose is always to examine how the concept has evolved as it is designed and evaluated. The results at this intermediate stage are presented to a team of reviewers which may include representatives of the customer, of your company’s management, and experts in the field.  The purpose is to gain an approval to continuing the process to its ultimate conclusion.  Topics to be covered in the review should include:

• Design objective
• Design requirements
• Review of general concept
• Discussion of the development of the design
• Presentation of all analyses
• Discuss any problems that have been, or need to be, overcome
• Risk management update
• Cost update
• Schedule update

17. Evaluate critiques from review – The reviewers will likely have questions and/or suggestions arising from the review. These need to be examined and evaluated by the design team.
18. Continue detail design development – The design team needs to take the project from the approved preliminary design to a finished design that is capable of being produced.
19. Continue detail analysis - A thorough analysis of the detailed components must be conducted using computer modeling, finite element analysis, component prototyping and testing. Depending on the project, this may include an assessment of material stress, component dynamics, thermodynamics, heat transfer, wear capability, part tolerances, et cetera.
20. Produce detail drawings - This includes producing 3D models or 2D drawings capable of being used in the manufacturing and assembly process.
21. Critical Design Review - This review goes by different names in different industries. However its purpose is always to examine how the final design has been developed and evaluated. The results at this critical stage are presented to a team of reviewers which may include representatives of the customer, of your company’s management, and experts in the field.  The purpose is to gain final approval to continuing the process to its ultimate conclusion.  Topics to be covered in the review should include:

• Design objective
• Design requirements
• Design concept
• Design details
• Analysis details
• Updated cost
• Updated schedule
• Risk management update
• Concluding statements and recommendations

22. Prepare final report and documentation – The project is never finished until the documentation is complete. The members of the design team may well be moved on to other tasks. There needs to be a complete record of the design, the rationale and analysis which supported it, so that in the future when a problem occurs, or when a subsequent change is desired, the engineers assigned to the project can pick up where the previous design team concluded.

Serial versus Concurrent Design Process

 Traditionally, engineering design was conducted in a Serial Design Process.  That is, steps in the process all occurred sequentially.  The initial design concept was passed to a designer, who took the concept to a detailed design.  This design was then passed to engineers who performed the stress, thermal and dynamic analyses.  If one of them found a problem with the design, it was sent back to the designer, who had to make changes.  Once the changes were made, the design was passed back to the analysts, who again performed their work on it.  If any of them found a problem, then it went through this loop again.  Then the design went to prototyping and testing, if any problems were found there, it had to be sent all the way back to the designer, and then again to the analysts.  After these iterations were finished, the design was passed over to the manufacturing regime.  Here the manufacturing engineers began the process of determining how to manufacture the component.  If they found any problems that kept the component from being easily manufactured, the design was sent all the way back to the beginning for a redesign.  This then led to it being routed through the analysis process again, then prototyping and back to manufacturing.  This same process occurred with the purchasing department and any external vendors. 

More recently, engineering businesses have moved toward an improved process called the Concurrent Design Process.  In this approach, a team is formed which contains experts in design, all analysis areas, prototyping and test, manufacturing, and even purchasing.  This team is often called an Integrated Product Team.  The members of this team work closely together, such that when a concept is to be developed, the analysts are working alongside the designer, examining the design as it evolves and suggesting how problems can be anticipated and avoided.  Similarly, the manufacturing engineer is now involved from the beginning and can make recommendations throughout the process that improve the manufacturability of the design.  By having all aspects of the design process represented on the team, the efficiency of the design process is greatly improved and the time required to bring a product to production can be greatly reduced.

Throughout many industries, this change has been occurring in recent years.  Two changes were required in order for this improvement in process to come about.   The first change was cultural.  The design and manufacturing sides of a company must stop looking at each other as separate and realize that only by working together can they significantly improve their company’s ability to compete with new products.  The second thing that was needed for concurrent engineering to work was an improvement in technology.  Specifically, what made this possible was the ability to quickly and efficiently create 3D models of new designs and the ability to quickly mesh these into Finite Element Models and produce stress, dynamics, and heat transfer results.  Technology that lets models be built, analyzed, modified, and re-analyzed in a matter of hours, not days or weeks, makes it possible for analysis and design to actually occur simultaneously.  Fortunately, the technology is in hand, and the Concurrent Engineering process is saving many companies both time and money.

 Diagram 3.1 shows how the Serial Engineering Process works.  It is easy to understand how this process became very time consuming.

Diagram 3.1

Text version

Diagram 3.2 represents The Concurrent Design Process:

Diagram 3.2

Text version

Case Study

The following is a case study example provided by an engineer who spent quite a few years as a dynamics analyst in a company that designed and built gas turbine engines for aeroplanes and industrial power generation.  This is his story of concurrent versus serial engineering.

“When I first joined the company, I was part of the dynamics analysis group.  We performed the vibration analysis of engine components and analysed the system dynamic characteristics of entire engines and their installations.  A job would come to me when a designer suddenly appeared in my doorway with drawings under his arm.  He would lay them out on my desk and explain to me what his design was for and go over all the aspects of it.  Then he would go away and leave me to work on it for a few weeks, laying out a model, inputting the model to the computer, and running the necessary analyses to ensure that it worked.  I probably would not see the designer again during that time.  I knew, through experience, that somewhere else in the building was a stress analyst, and a heat transfer analyst doing exactly the same things I was.  But unless we bumped into each other in the lunch room, we never even spoke to each other.  In fact, we might not even know each other.  When I finished my modelling and analysis, I would call the designer and show him my results.  Perhaps everything looked fine from my stand point.  But just as likely, there were issues that had arisen that might force him to modify his design.  If so, he would go away and make the changes, then return with a new version and we would repeat the process.  Of course, even if my analysis had gone well, if the results coming from the stress or heat transfer analysts did not look so good, the designer still had to make changes, and if those changes could in any way effect my results, then he had to bring the new version back to me to be analysed again.

This would go on and on until the designer, and all the independent analysts were happy.  We would all document our results and the finished design would be sent across the street to the manufacturing plant.   You would have thought that “across the street” was like crossing the Grand Canyon.  No one from our side ever went there.  And all I knew about the manufacturing side of the company, was that folks on my side claimed that manufacturing couldn’t do anything right, and was incapable of making a decent part.  At least, that was what I would hear from the designers, who were always dissatisfied with the quality of the parts produced and/or the rejection rate on parts failing inspection.

Once, I had to attend a meeting on the other side of the street, and all I heard from the denizens of that world were how awful the designs were, and how the designers and analysts kept coming up with parts that couldn’t be made.  No one on either side of the street would really talk to the other side.  We lived and operated in separate worlds.  We lived in the world of Serial Engineering.  Each person did their little job and then passed it on to someone else.  And if anything went wrong, then the process backed up and started over again.  And a typical design could take up to ten years to get from concept to production.

During my years with the company, I saw a huge change in approach and philosophy.  By the time I had been there 15 years, we had begun to work more closely with the designers, keeping in touch everyday so that they knew what was going on with our analysis and could begin thinking about changes and iterating on them with us as we went along.   They would also come to us early with their concept and we would help formulate the preliminary configurations, avoiding any immediately obvious missteps.  By the time I left the company, I led an Integrated Product Team.  I had designers, analysts, graphics experts, a manufacturing engineer, and even a purchasing agent on the team.  We all worked in the same room, with no walls or barriers, and everyone knew what everyone else was doing at all times.  So our manufacturing engineer was always looking at what was being designed, pointing out what aspects would be difficult to make in the manufacturing shop, and steering the design toward a result that would be easy and efficient to produce.  Our purchasing agent was constantly working between our designers and our outside vendors, virtually bringing the vendors into the team.   Designs were developed while analyses of those designs were going on at the exact same time.  During my last assignment, we brought an entire design from concept to hardware in 13 months.” 

Requirements and Constraints

The engineering design team must consider many constraints when taking on a project.  This topic will discuss technical, financial, schedule, legal, social, and ethical constraints that may be faced.

Engineering designs are solutions to open-ended problems.  In the real world, most problems that you solve will be open-ended problems for which there is not just ONE solution.  Rather, there are a multiplicity of possible solutions, and it may not be obvious which (or even if) one single solution is the best.  The greatest challenge you face is when there are multiple paths to a variety of multiple solutions, and YOU have to propose the one you think is optimum.

What is the best solution?  Simply put, the best solution is the simplest, least expensive design that meets all the project requirements and constraints.

You can always design it with more bells and whistles.  You can always design it to be more complicated and impressive.  You can always make your design more glorious and more expensive.  But why would you want to over-design it to exceed the requirements with more complexity than required and more expense than necessary?

The best solution is the simplest, least expensive design that meets the project requirements, including all financial, schedule, social, legal and ethical constraints

Some types of constraints:

Technical

When an engineering design team begins to evaluate a new project, they must determine the technical requirements, or constraints, that will govern the product.  Are requirements and constrains the same things?  They certainly are related.  Requirements are things that the product must do, be, or have.  Such as, “it must provide light, and have a simple switch that turns it on and off.”    Constraints are things that restrict the product.  Such as, it must not require more power than can be supplied by two 1.5 volt batteries and it must be small and light enough to be carried by hand.  These could be requirements for a simple battery powered torch or flashlight.   In the end, the requirements and constraints define the design space that encompasses all the possible solutions.

Requirements or constraints could also specify that the product being designed must interface with other products.  Consider when two teams are working on interrelated products, that have the requirement to fit together.   The teams, therefore, have constraints that they cannot violate, which derive from the other part.  This requires the two design teams to work together so as to ensure that the interfaces between the two components align to permit them to work properly together.

Cost

What do you believe is the most important objective in a design project?  Is it coming up with the best possible design?  Not necessarily. While the design must meet requirements, it can be argued that there is absolutely no justification for designing something one bit “better” than the technical requirements require. 

Some people might guess that the most important thing is cost, which, of course, directly relates to the profit that your business makes.  Cost is certainly an important constraint on a project, because if you spend more money than your company has available while creating and producing your design, then you may be out of business before it ever gets into production.  Additionally, if the product you design costs more to make than it can be competitively sold for in the marketplace, then your project is unlikely to be considered a success.

Schedule

 In today’s engineering world, another major constraint is the project schedule.  Most engineering efforts in industry nowadays are both schedule intensive and schedule driven.  That is, they have very tough and aggressive schedules which you have to work very hard to meet.  It is not uncommon for a major project funded either by government or commercial interests, to have clauses in the contract that impose heavy financial penalties for any delay relative to the agreed delivery date.  There may also be the potential for contractual financial bonuses if the product is delivered ahead of the agreed schedule.  Therefore, knowing how to manage a project’s schedule is of great importance to the project’s success. Meeting the schedule may be the biggest challenge of the project.  The way that most design teams will manage their time is to create a Project Schedule, and have someone assigned to continually track where the team is on the schedule, this will be discussed in more detail later in this module.

Legal

Businesses, and their employees, must always be aware of the potential impact of violating the law.  Companies and individuals can both be liable and subject to fines and penalties in the event that they are proven to have knowingly violated the law.  Corporate executives have even been known to be sentenced to jail terms if their actions cross the legal boundary and cause harm to others.  While the potential impacts vary, depending on the company where the illegal action takes place, it is always important that the engineers working on a project have in mind the potential ramifications of violating the law.  Some companies have been known to suffer severe damage to their reputation when it becomes public knowledge that they have wittingly violated legal standards.  The loss of consumer confidence can have a major negative impact on corporate sales and profits.  There also exists the potential that consumers who have suffered injury or expense due to an illegal action by a business can sue in court to claim monetary compensation for their loses.  One area within the legal realm is patent law.  During the design phase of a project, engineers must ensure that they are aware of patents that may impact their design, and avoid illegal infringement of those patents.  With all of these potential impacts, it behooves the design team to be aware of the law as it impacts their design activities, and to ensure that their actions do not lead to a violation.

Social/Ethical

Engineers can create solutions to societal problems in a wide range of areas including sustainability, environmental pollution, housing, etc.  They can also develop solutions that result in increased opportunity for employment, safer work places, and lower living costs.   Consider the creation of new products that bring about new factories and jobs, improved machinery which does not place workers at risk of injury, or reduced energy costs that eat less of a family’s available income.  In these cases, engineers can become heroes to society.  However, consider that engineering mistakes can result in loss of life and property, environmental damage and lower quality of work life.  Consider the impact of a poorly designed transportation system, an oil spill, or poor air quality in third world cities due to over-industrialization.  Design engineers should always consider their efforts from the perspective of how it will impact society.  Engineers should always execute their tasks with consideration to the appropriate ethical behaviour.

Putting Things in Perspective

One must always keep things in perspective.  The designer can almost always see a way to improve the design, if given just a little more time and resource.  But is this always the best course of action?

Design Engineer’s Viewpoint:  Design is an iterative process.  The optimum design always involves one more iteration than the number you have currently performed.  This is true at any point in time.

Program Manager’s Viewpoint:  There comes a point in time in any design process where it becomes necessary to ignore the design engineer and proceed with production.

Summary

The engineering design process is the route by which a design engineer, or an engineering design team plots its course through the challenges involved in developing a solution to a design problem.  The process involves a number of aspects which have been delineated in this module, beginning with team member assessments and preliminary scheduling, then moving on to requirements capture and brainstorming of concepts which will be evaluated to down-select to a single approach.  That concept then proceeds through design and evaluation, utilizing a process which evaluates numerous aspects of the design and is reviewed on multiple occasions, leading to a result which should meet all of the

References and Bibliography

BrainyQuote (2017). Available at: <https://www.brainyquote.com/quotes/albert_schweitzer_112973>

Dym, C. & Little, P. (2009). Engineering Design, 3^rd edition.  Hoboken, NJ, USA: Wiley.

Heizer, J., Munson, C. & Render, B. (2017). Operations Management.  New York: Pearson.

Horenstein, M. (2002).  Design Concepts for Engineers, 4^th Edition. Upper Saddle River, NJ, USA: Prentice.

Hulme, D (2003). “Positively No Absolutes” Available at: <http://www.vision.org/visionmedia/philosophy-and-ideas-absolutes-right-and-wrong-715>

Meredith, J. & Mantel, S. (2012).   Project Management, 8^th edition. Hoboken, NJ,

Passiton, <https://www.passiton.com/inspirational-quotes/3370-relativity-applies-to-physics-not-ethics>